[Security Solution][Exceptions] Add lowercase normalized fields for case-insensitive matching#79
Conversation
jonathan-buttner
left a comment
There was a problem hiding this comment.
Should these changes go in the Ext section under each file since they modify the core ECS fields? Thoughts @marshallmain ?
custom_schemas/custom_process.yml
Outdated
| - name: text | ||
| type: text | ||
|
|
||
| - name: parent.command_line |
There was a problem hiding this comment.
process.parent isn't explicitly defined in the core ECS as of version 1.6. It's now created by duplicating all the process fields and storing them on process.parent. So I think you can remove the parent.* one heres since you already have them defined on process.
| rm -rf $(PACKAGES_DIR) | ||
| mkdir -p $(PACKAGES_DIR)/endpoint/$(PACKAGE_VERSION) | ||
| cp -r $(ROOT_DIR)/package/endpoint/ $(PACKAGES_DIR)/endpoint/$(PACKAGE_VERSION) | ||
| cp -r $(ROOT_DIR)/package/endpoint/* $(PACKAGES_DIR)/endpoint/$(PACKAGE_VERSION) |
|
@jonathan-buttner @marshallmain Let's talk about this today... these are just multi-field additions to existing fields, so I was thinking we could get away with this... if they go into Alternatively, we could use this as a stop-gap and push to get these included in ECS? |
b911543 to
77fb983
Compare
Yeah that makes sense. I'm happy to chat whenever. |
|
I think it's simpler to add the extra multi-fields to the core ECS fields rather than having a new custom field. We've had user confusion about the existing multi-fields on core ECS fields ( The downside is if ECS does add official |
| - name: caseless | ||
| type: keyword | ||
| normalizer: lowercase | ||
| - name: text |
There was a problem hiding this comment.
@madirey since ECS already defines the path.text as type text, if you remove that from here does it still get outputted or does it get removed?
Basically I'm wondering if we can avoid having to define the -name: text fields in these files.
There was a problem hiding this comment.
Looks like ECS doesn't support merging custom and core multi_fields. I'll open an issue in the ECS repo.
The general guidance from the ingest team is to avoid making breaking changes until a major version change @madirey It'd probably be a good idea to create a ticket in ECS to discuss the |
|
@jonathan-buttner At first, ingest manager does try to update the mapping. This works if there is no conflict. If there is a conflict, it will update the template and trigger a rollover. |
This PR adds
*.caselessmultifields for fields that will be used for case-insensitive exceptions, so that the detection engine can perform case-insensitive comparisons in the same way that the endpoint does (without tokenization).Related: